Protocol Level Control for System on a Chip (SOC) Agent Reset and Power Management

ABSTRACT

A system for consistently implementing reset and power management of IP agents on a System on a Chip (SoC). When IP agents undergo a reset, an individual negotiation takes placed between an interconnect and each IP agent over a link. Each IP agent can emerge from reset at its own time schedule, independently of the timing of the other IP agents. The interconnect may be configured as a proxy for any IP agent that is inoperable, including prior to reset, when in a power-down mode, or malfunctioning.

RELATED APPLICATION(S)

This application is a continuation of and claims priority to U.S.Non-Provisional patent application Ser. No. 17/656,378, filed on Mar.24, 2022 which is a continuation of and claims priority to U.S.Non-Provisional patent application Ser. No. 16/368,443, filed on Mar.28, 2019, which is now U.S. Pat. No. 11,340,671, issued on May 24, 2022,which in turn claims priority to U.S. Provisional Patent ApplicationSer. No. 62/691,117, filed on Jun. 28, 2018, and to U.S. ProvisionalPatent Application Ser. No. 62/650,589, filed on Mar. 30, 2018, thedisclosures of which are incorporated by reference herein in theirentireties.

BACKGROUND

The present application is directed to a System on a Chip (SoC), andmore particularly, to a system and method for consistently implementingreset and/or power management functionality on SoC, which in turn,provides a more uniform system software view of SoCs, particularlyacross families of SoCs.

A System on a Chip (“SoC”) is an integrated circuit that includesmultiple sub-systems, often referred to as Intellectual Property (“IP”)agents. IP agents are typically “reusable” blocks of circuitry designedto implement or perform a specific function. By using IP agents, thetime and cost of developing complex SoCs can be significantly reduced.

SoCs typically include a system controller and an interconnect, such asa bus or Network on a Chip (NoC). The system controller runs systemsoftware and is provided to manage the overall operation of the SoC. Thevarious IP agents are connected to the interconnect via one or morelinks and communicate with one another via the interconnect.

SoC developers commonly use disparate IP agents, often from multiplevendors. Each IP agent will ordinarily implement its own uniqueprocedures for reset. From the perspective of the system controller andthe interconnect on the SoC, this is problematic for several reasons.

A typical SoC will normally have multiple IP agents connected to theinterconnect. Upon reset, each of the IP agents will likely emerge fromthe reset state at different times due to the unique reset procedureseach uses. The different times each IP agent emerges from reset cancause significant problems. If a source IP agent generates a transactionfor a destination IP agent that is still in reset, then the (1)destination IP agent is unable to process the request and (2) source IPagent never receives a reply. As a result, the entire system may gethung up, possibly requiring a system-wide reset.

One known approach to prevent hang-ups is to design and place circuitryintermediate each link, between the interconnect and each IP agent. Thepurpose of this circuitry is to make sure that all the IP agentsconnected to the interconnect emerge from reset during the same clockcycle. This approach, however, has drawbacks for several reasons:

-   -   1. The design of the intermediate circuitry requires time and        effort that will often delay the development of the SoC.    -   2. The intermediate circuitry, from one SoC to another, is        typically developed by different design teams. As a result, the        intermediate circuitry is usually different from one SoC to the        next, or even between different sub-systems on the same SoC.    -   3. The complexity of the circuitry normally means the number of        IP agents that can be connected to a given interconnect is        limited. The practical effect of this restriction is that more        interconnect levels are needed to accommodate a given number of        IP agents. The overall complexity of the SoC is therefore        increased.

On occasion, IP agents malfunction. For example, IP agents may injectspurious transactions onto the interconnect, may fail to respond to areceived transaction, generate an exception message, etc. In certainsituations, the malfunctioning IP agent may need to be reset. Withcurrent SoC interconnect standards, there is no standardized IP agentreset mechanism. Either the entire SoC has to be reset, or intermediarycircuitry needs to be designed to perform the necessary isolation,reset, and re-introduction of the IP to the system, etc.

Power management is also not addressed with certain current SoCinterconnect standards. The Advanced Microcontroller Bus Architecture(AMBA) protocol, for instance, does not address power management, andprovides no method for intentionally powering down or turning off IPagents. To provide this capability, power management functionalitytypically needs to be custom designed into the SoC on a chip-by-chipbasis, by developing for instance, additional intermediate circuitry onthe links for handing power management.

Many companies offering multiple SoCs will share certain amounts of thesystem software among similar devices to reduce the time to market.However, even with SoCs that are similar, the software typically cannotsimply be ported from one device to another, even in situations wherethe IP agents may be the same. If there are minor differences in anyintermediate circuitry used for reset and/or power management, thesystem software may need to be modified and debugged for each device.

Companies that develop a large number of SoCs are thus challenged with(1) developing customized circuitry for implementing reset and possiblypower management for each device and (2) modifying and debugging thesystem software for each device. This effort, across multiple devices isexpensive, complex and time consuming, reducing the ability to quicklybring products to market.

A system for consistently implementing reset and power management of IPagents on SoCs, removing the need for customization, and which leads toa consistent system software view among multiple SoCs, is thereforeneeded.

SUMMARY

A system for consistently implementing reset and power management of IPagents on SoCs, removing the need for customization, and which leads toa consistent system software view among multiple SoCs, is disclosed.

In one embodiment, the system includes one or more IP agents, aninterconnect and one or more links between the IP agents and theinterconnect respectively. When the IP agents undergo a reset, anindividual negotiation takes place between the interconnect and each IPagent over the link. With the individual negotiations, each IP agent canemerge from reset at its own time schedule, independently of the timingof the other IP agents. Upon emerging from reset, each IP agent becomes“transaction ready” and is introduced to the interconnect, becomingvisible to other elements connected to the interconnect, such as thesystem controller.

In another embodiment, the interconnect may be configured as a proxy forany IP agent that is inoperable. This feature is beneficial because itprevents system wide hang ups that may otherwise occur when an IP agentis targeted with a transaction (1) prior to being transaction ready, (2)malfunctioning and/or (3) inoperable when in a powered down state. Withthe interconnect acting as a proxy, an exception message can be sent tothe source sending the transaction, preventing a hang up caused by thesource waiting indefinitely for a response from the target IP agent.

In yet other embodiments, the ability to arrange for the interconnect toact as a proxy for an IP agent enables (1) IP agents to be individuallyreset and (2) IP agents to be placed in a power saving state. In variousembodiments, the power saving state can include one of several modes,including a low power, operational mode, a low power inoperable modewith state information either maintained or not retained, or a power offmode.

The present invention thus solves a number of issues. It eliminates theneed to create custom circuitry for (1) managing each IP agent to emergefrom reset during the same time/clock cycle and (2) power management ofIP agents. Instead, the present invention advantageously provides auniform implementation for both these functions, which leads to aconsistent system software view among multiple SoCs. With thisconsistent software view, much of the custom design and softwaremodifications across families of SoCs is eliminated, saving developmentcosts, reducing complexity, and providing a quicker time to market.

BRIEF DESCRIPTION OF THE DRAWINGS

The present application and the advantages thereof, may best beunderstood by reference to the following description taken inconjunction with the accompanying drawings in which:

FIG. 1 is a block diagram of a shared interconnect for a System on aChip (SoC) in accordance with a non-exclusive embodiment.

FIG. 2 is an exemplary packet of a transaction in accordance with anon-exclusive embodiment.

FIG. 3A is a logic diagram illustrating an arbitration element inaccordance with a first non-exclusive embodiments.

FIG. 3B is a logic diagram illustrating an arbitration element inaccordance with a second non-exclusive embodiment.

FIG. 4 is a flow diagram illustrating operational steps for arbitratingand sending portion(s) of transactions over virtual channels of theshared interconnect in accordance with a non-exclusive embodiment.

FIG. 5 illustrates a first example of the interleaving the transmissionof portions of different transactions over virtual channels of theshared interconnect in accordance with a non-exclusive embodiment.

FIG. 6 illustrates a second example of the interleaving the transmissionof portions of different transactions over virtual channels of theshared interconnect in accordance with a non-exclusive embodiment.

FIG. 7 illustrates is a block diagram of two shared interconnects forhandling traffic in two directions in accordance with anothernon-exclusive embodiment of the invention.

FIG. 8 illustrates a block diagram of an SoC having reset, powermanagement and quiesce functionality in accordance with a non-exclusiveembodiment of the invention.

FIG. 9 is a flow diagram showing an IP agent reset sequence inaccordance with a non-exclusive embodiment of the invention.

FIG. 10 is a flow diagram showing a reset sequence for a malfunctioningIP agent in accordance with a non-exclusive embodiment of the invention.

FIG. 11 is a flow diagram illustrating a power down/up sequence for anIP agent in accordance with a non-exclusive embodiment of the invention.

FIG. 12 is a flow diagram illustrating a power down/up sequence for anIP agent in accordance with a non-exclusive embodiment of the invention.

FIG. 13 is a flow diagram illustrating a power down/up sequence for anIP agent in accordance with a yet another non-exclusive embodiment ofthe invention.

FIG. 14 is a flow chart illustrating the steps for placing a link in aquiescent state.

FIG. 15A-15D are flow diagrams illustrating various “wake-up” sequencesfor an IP agent.

In the drawings, like reference numerals are sometimes used to designatelike structural elements.

DETAILED DESCRIPTION

The present application will now be described in detail with referenceto a few non-exclusive embodiments thereof as illustrated in theaccompanying drawings. In the following description, numerous specificdetails are set forth in order to provide a thorough understanding ofthe present disclosure. It will be apparent, however, to one skilled inthe art, that the present disclosure may be practiced without some orall of these specific details. In other instances, well known processsteps and/or structures have not been described in detail in order tonot unnecessarily obscure the present disclosure.

Many of the integrated circuits under development today are extremelycomplex. As a result, many chip designers have resorted to the System ona Chip or “SoC” approach, interconnecting a multiple sub-systems or IPagents on a single piece of silicon. SoCs are now available or are beingdeveloped for wide variety of applications, such as consumer devices(e.g., handheld, mobile phones, tablet computers, laptop and desktopcomputers, media processing etc.), virtual or augmented reality (e.g.,robotics, autonomous vehicles, aviation, etc.), medical instrumentation(e.g., imaging, etc.), industrial, home automation, industrial (e.g.,smart appliances, home surveillance, etc.) and data center applications(e.g., network switches, attached storage devices, etc.).

The present application is broadly directed to an arbitration system andmethod for arbitrating access to a shared resource. Such a sharedresource can be, for example, a bus interconnect, a memory resource, aprocessing resource, or just about any other resource that is sharedamong multiple vying parties. For the sake of illustration, the sharedresources as described in detail below is an interconnect that is sharedby a plurality of sub-systems on a System on a Chip or “SoC”.

With an SoC, as described in detail below, there are a plurality ofsub-systems that exchange traffic with one another in the form oftransactions, the shared resource is a physical interconnect, varioustransactions, or portions thereof, are transmitted over a multiplicityof virtual channels associated with the shared interconnect and one of anumber of different arbitration schemes and/or priorities may be used toarbitrate access to the shared interconnect for the transmission oftransactions between the sub-functions.

Transaction Classes

Within the above-mentioned shared interconnect used for SoCs, there areat least three types or classes of transactions, including Posted (P),Non-posted (NP) and Completion (C). A brief definition of each isprovided in Table I below.

TABLE 1 Transaction Class Description Posted (P) A transaction thatrequires no response (e.g., a write operation). Non-posted (NP) Atransaction that requires a response transaction from the destinationagent (e.g., a read or write operation). Completion (C) A responsetransaction for a non-posted transaction.

A Posted transaction, such as a write, requires no response transaction.Once a source writes data to a designated destination, the transactionis finished. With a Non-posted transaction, such as either a read or awrite, a response is required. However, the response is bifurcated as aseparate Completion transaction. In other words with a read, a firsttransaction is used for the read operation, while a separate, butrelated, Completion transaction is used for returning the read contents.With a Non-posted write, a first transaction is used for the write,while a second related Completion transaction is required for theconfirmation once the write is complete.

Transactions, regardless of the type, can be represented by one or morepackets. In some circumstances, a transaction may be represented by asingle packet. In other circumstances, multiple packets may be needed torepresent the entire transaction.

A beat is the amount of data that can be transmitted over the sharedinterconnect per clock cycle. For example if the shared interconnect isphysically 128 bits wide, then 128 bits can be transmitted each beat orclock cycle.

In some circumstances, a transaction may need to be divided intomultiple portions for transmission. Consider a transaction having asingle packet that has a payload that is 512 bits (64 bytes). If theshared interconnect is only 128 bits wide (16 bytes), then thetransaction needs to be segmented into four portions (e.g.4.times.128=512) and transmitted over four clock cycles or beats. On theother hand if a transaction is only a single packet that is 128 bitswide or less, then the entire transaction can be sent in one clock cycleor beat. If the same transaction happens to include additional packets,then additional clock cycles or beats may be needed.

The term “portion” of a transaction is therefore the amount of data thatcan be transferred over the shared interconnect during a given clockcycle or beat. The size of a portion may vary depending on the physicalwidth of the shared interconnect. For instance, if the sharedinterconnect is physically 64 data bits wide, then the maximum number ofbits that can be transferred during any one cycle or beat is 64 bits. Ifa given transaction has a payload of 64 bits or less, then the entiretransaction can be sent over the shared interconnect in a singleportion. On the other hand if the payload is larger, then the packet hasto be sent over the shared interconnect in multiple portions. Atransaction with a payload of 128, 256 or 512 bits requires two (2),four (4) and eight (8) portions respectively. As such, the term“portion” or “portions” should therefore be broadly construed to meaneither part of or an entire transaction that may be sent over the shareinterconnect during any given clock cycle or beat.

Streams

A stream is defined as the pairing of a virtual channel and atransaction class. For instance, if there are four (4) virtual channels(e.g., VC0, VC1, VC2 and VC3) and three (3) transaction classes (P, NP,C), then there are a maximum of twelve (12) different possible streams.The various combinations of virtual channels and transaction classes aredetailed below in Table II.

TABLE II Stream VC/TC Number Combination  1 VC0/NP  2 VC0/P  3 VC0/C  4VC1/NP  5 VC1/P  6 VC1/C  7 VC2/NP  8 VC2/P  9 VC2/C 10 VC3/NP 11 VC3/P12 VC3/C

It should be noted that the number of transaction classes discussedabove is merely exemplary and should not be construed as limiting. Onthe contrary, any number of virtual channels and/or transaction classesmay be used.

Arbitration Over Virtual Channels of a Shared Interconnect

Referring to FIG. 1, a block diagram of an arbitration system 10 isshown. In a non-exclusive embodiment, the arbitration system is used forarbitrating access by a number of sub-functions 14 (i.e., IP₁, IP₂ andIP₃) to a shared interconnect 12 attempting to send transactions toupstream sub-functions 14 (i.e., IP₄, IP₅ and IP₆).

The shared interconnect 12 is a physical interconnect that is N databits wide and includes M control bits. The shared interconnect 12 isalso one-directional, meaning it handles traffic only from a source(i.e., IP₁, IP₂ and IP₃) to a destination (i.e., IP₄, IP₅ and IP₆).

In various alternatives, the number of N data bits can be any integer,but typically is some power of the number 2 (e.g., 2¹, 2², 2³, 2⁴, 2⁵,2⁶, 2⁷, 2⁸, 2⁹ etc.) or (2, 4, 6, 8, 16, 32, 64, 128, 256 etc.) bitswide respectively. With most real-world applications, the number of Nbits is either 32, 64, 128, 256 or even 512. However, it should beunderstood that these widths are merely illustrative and should not beconstrued as limiting in any manner.

The number of control bits M may also vary and be any number.

One or more logical channels (not illustrated), hereafter referred to as“virtual channels” or “VCs” are associated with the shared interconnect12. Each virtual channel is independent. Each virtual channel may beassociated with multiple independent streams. The number of virtualchannels may widely vary. For example, up to thirty-two (32) or morevirtual channels may be defined or associated with the sharedinterconnect 12.

In various alternative embodiments, each virtual channel may be assigneda different priority. One or more virtual channel(s) may be assigned ahigher priority, while one or more other virtual channel(s) may beassigned a lower priority. The higher priority channels are awarded orarbitrated access to the shared interconnect 12 over the lower priorityvirtual channels. With other embodiments, each of the virtual channelsmay be given the same priority, in which case, no preference is given toone virtual channel versus another when awarding or arbitrating accessto shared interconnect 12. In yet other embodiments, the priorityassigned to one or more of the virtual channels may also dynamicallychange. For instance, in a first set of circumstances, all the virtualchannels may be assigned the same priority, but in a second set ofcircumstances, certain virtual channel(s) can be assigned a higherpriority than other virtual channel(s). Thus as circumstances change,the priority scheme used among the virtual channels can be varied tobest meet current operating conditions.

Each of the sub-systems 14 is typically a block of “reusable” circuitryor logic, commonly referred to as an IP core or agent. Most IP agentsare designed to perform a specific function, for example, controllersfor peripheral devices such as an Ethernet port, a display driver, anSDRAM interface, a USB port, etc. Such IP agents are generally used as“building blocks” that provide needed sub-system functionality withinthe overall design of a complex system provided on an integrated circuit(IC), such as either an Application Specific Integrated Circuit (ASIC)or a Field Programmable Gate Array (FPGA). By using a library ofavailable IP agents, a chip designer can readily “bolt” together variouslogic functions in the design of a more complex integrated circuit,reducing design time and saving development costs. Although sub-systemagents 14 are described above in terms of a dedicated IP core, it shouldbe understood that this is not a necessary requirement. On the contrary,a sub-system 14 can also be a collection of IP functions connected to orsharing a single port 20. Accordingly, the term “agent” should bebroadly construed as any type of sub-system connected to a port 20,regardless if the sub-system performs a single function or multiplefunctions.

A pair of switches 16 and 18 provides access between each of thesub-system agents 14 and the shared interconnect 12 via dedicated accessports 20 respectively. With the exemplary embodiment shown:

(1) The sub-system agents IP₁, IP₂, and IP₃ connect with switch 16 viaaccess Port 0, Port 1 and Port 2 respectively.(2) The sub-system agents IP₄, IP₅, and IP₆ connect with switch 18 viaPort 3, Port 4 and Port 5 respectively.(3) In addition, an access port 22, via the interconnect 12, providessub-system agents IP₄, IP₅, and IP₆ access to switch 16 in theaggregate.

The switches 16 and 18 perform multiplexing and de-multiplexingfunctions. Switch 16 selects up-stream traffic generated by thesub-system agents IP₁, IP₂, and/or IP₃ and sends the traffic downstreamover the shared interconnect 12. At the switch 18, a de-multiplexingoperation is performed and the traffic is provided to a targetsub-system agent (i.e., either IP₄, IP₅, or IP₆).

Each access port 20 has a unique port identifier (ID) and provides eachsub-system agent 14 dedicated access to either switch 16 or 18. Forinstance, sub-system agents IP₁, IP₂ and IP₃ are assigned to accessports Port 0, Port 1 and Port 2 respectively. Similarly, the sub-systemagents IP₄, IP₅ and IP₆ are assigned access ports Port 3, Port 4 andPort 5 respectively.

Besides providing ingress and egress points to/from the switches 16, 18,the unique port IDs 20 are used for addressing traffic between thesub-system agents 14. Each Port 20 has a certain amount of allocatedaddressable space in system memory 24.

In certain non-exclusive embodiments, all or some of the access ports 20can also be assigned a “global” port identifier as well their uniqueport ID. Transactions and other traffic can be sent to all or some ofthe access ports assigned to the global port identifier. Accordingly,with the global identifier, transactions and other traffic can be widelydisseminated or broadcast to all or some of the access ports 20,obviating the need to individually address each access port 20 using itsunique identifier.

The switch 16 also includes an arbitration element 26, AddressResolution Logic (ARL) 28 and an address resolution Look Up Table (LUT)30.

During operation, the sub-system agents IP₁, IP₂ and IP₃ generatetransactions. As each transaction is generated, it is packetized by theoriginating sub-system agent 14 and then the packetized transaction isinjected via the corresponding port 20 into a local switch 16. Forinstance, portions of transactions generated by IP₁, IP₂ and IP₃ areprovided to switch 16 by via ports Port 0, Port 1 and Port 2respectively.

The ports 20 each include a number of first-in, first-out buffers (notillustrated) for each of the virtual channels associated with theinterconnect channel 12 respectively. In a non-exclusive embodiment,there are four (4) virtual channels. In which case, each port 20includes four buffers, one for each virtual channel Again, it should beunderstood that the number of virtual channels and buffers contained inthe ports 20 may vary and is not limited to four. On the contrary, thenumber of virtual channels and buffers may be more or less than four.

If a given transaction is represented by two (or more) portions, thoseportions are maintained in the same buffer. For instance, ifinterconnect 12 is 128 data bits wide and a transaction is representedby a packet containing a payload of 512 bits, then the transaction needsto be segmented into four (4) portions that are transmitted over fourclock cycles or beats. On the other hand if the transaction can berepresented by a single packet having a payload of 64 bits, then thesingle portion can be transmitted in one clock cycle or beat. Bymaintaining all the portion(s) of given transaction in the same buffer,the virtual channels remain logically independent. In other words, allthe traffic associated with a given transaction is always sent over thesame virtual channel as a stream and is not bifurcated over multiplevirtual channels.

The arbitration element 26 is responsible for arbitrating among thecompeting buffered portions of transactions maintained by the variousaccess ports 20. In a non-exclusive embodiment, the arbitration element26 performs an arbitration every clock cycle, provided multiplecompeting transactions are available. The arbitration winner per cycleyields a portion of a transaction, from one of the sub-systems IP₁, IP₂and IP₃, that is granted access to and is transmitted over theinterconnect 12.

When generating transactions, the source sub-system IP₁, IP₂ and IP₃ordinarily knows the address in the address space for the possibledestination sub-system agents IP₄, IP₅ and IP₆, but does not know theinformation (e.g., the Port IDs 20 and/or 22) needed to route thetransactions to their destinations. In one embodiment, the local AddressResolution Logic (ARL) 28 is used for resolving the known destinationaddress into the needed routing information. In other words, a sourcesub-agent 14 may simply know that it wishes to access a given address insystem memory 24. The ARL 28 is therefore tasked to access the LUT 30and performs an address look up of the port(s) 20/22 along the deliverypath to the final destination corresponding to the specified address.Once the ports 20/22 is/are known, this information is inserted in adestination field in the packet(s) of the transaction. As a result, thepacket(s) is/are delivered to the ports 20/22 along the delivery path.As a general rule, downstream nodes along the delivery path do not haveto perform additional look up(s) since the required delivery informationis already known and included in the destination field of the packet(s).With other types of transactions, referred to as Source Based Routing(SBR) as described in more detail below, the source IP agent knows thedestination port address. As a result, the lookup performed by the ARL28 typically does not need to be performed.

In an alternative embodiment, not all the nodes within the interconnectrequire an ARL 28 and LUT 30. For nodes that do not have these elements,transactions without needed routing information can be forwarded to adefault node. At the default node, an ARL 28 and LUT 30 are accessed andthe needed routing information can then be inserted into the headers ofthe packet(s) of transactions. The default node is typically upstreamfrom the node without the ARL 28 and LUT 30. However, this is by nomeans a requirement. The default node, or nodes, can be located anywhereon the SoC. By eliminating ARLs 28 and LUTs 30 from certain nodes, theircomplexity can be reduced.

The ARL 28 may also be referred to as an “ordering point” because,besides decoding the forwarding destination for winning portion(s) oftransactions, it defines a sequence order for the winning portion(s) oftransactions within each virtual channel As each arbitration isresolved, regardless of whether or not the ARL 28 is used to perform anaddress port lookup, the winning portions of transactions are insertedinto a first-in, first out queue provided for each virtual channel Thewinning portions of transactions then await their turn for transmissionover the interconnect 12 in the buffer.

ARL 28 is also used for defining “upstream” and downstream” traffic. Inother words any transactions generated by the IP agents 14 associatedwith switch 16 (i.e., IP₁, IP₂ and IP₃) is considered upstream withrespect to the ARL 28. All transaction post the ARL 28 (i.e.,transmitted to IP₄, IP₅ and IP₆) is considered down-stream traffic.

The IP agents 14 associated with switch 16 (i.e., IP₁, IP₂ and IP₃) maycommunicate and send transactions to one another, either directly orindirectly. With direct communication, often referred to as Source BasedRouting (SBR), the IP agents 14 can send transactions to one another ina peer-to-peer model. With this model, the source IP agent knows theunique Port ID of its peer IP agents 14, bypassing the need to use theARL 28 to access the LUT 30. Alternatively, the transactions between theIP agents associated with the switch 16 can be routed using the ARL 28.With this model, similar to that described above, the source IP agentonly knows the address of the destination IP agent 14, but not theinformation needed for routing. The ARL 28 is then used to access theLUT 30, find the corresponding Port ID, which is then inserted into thedestination field of the packet(s) of the transaction.

Packet Format

The IP agents 14 create and process transactions over virtual channelsassociated with the interconnect 12. Each transaction typically is madeup of one or more packets. Each Packet typically has a fixed header sizeand format. In some instances, each packet may have a fixed sizedpayload. In other instances, packet payloads may vary in size, fromlarge too small, or even with no payload at all.

Referring to FIG. 2, an exemplary packet 32 is shown. The packet 32includes a header 34 and a payload 36. In this particular embodiment,the header 34 is sixteen (16) Bytes in size. It should be understoodthat this size is exemplary and either a larger size (e.g., more Bytes)or smaller size (e.g., fewer Bytes) packets may be used. It should alsobe understood that headers 34 of packets 32 do not necessarily have toall be the same size. In alternative embodiments, the size of packetheaders in a SoC may be variable.

The header 34 includes a number of fields including a destinationidentifier (DST_ID), a source identifier (SRC_ID), a payload sizeindicator (PLD_SZ), a reserved field (RSVD), a command field (CMD), aTAG field, a status (STS), a transaction ID field (TAG), an address orADDR field, a USDR/Compact payload field, a transaction Class or TCfield, a format FMT filed, and a Byte Enable (BE) field. The variousfields of the header 34 are briefly described in Table III below.

TABLE III Name of Field Description DST Specifies the corresponding PortID for the targeted IP agent 14. SRC Specifies the Port ID for thesending IP agent 14. PLD_SZ Specifies the size of the payload of thepacket. CMD Specifies the type of transaction/command the packetcontains. Exemplary commands may include Incremental Read, IncrementalWrite, Compact Read, Compact Write, Write to FIFO, DestructiveIncremental Read, Wrap, etc. TAG Specifies a transaction ID for thepacket. Transaction IDs are used for matching Non-posted transaction andtheir corresponding Completion transactions. When a Completiontransaction including a matching transaction ID in the TAG field isreceived, the corresponding Non- posted read or write operation iscomplete. ADDR Specifies the physical address in the system memory 24 ofthe request. USRD/Compact If the payload of the packet is sufficientlypayload small, it can be transported in this field in the header, notthe payload. This field can also be used to transport a private orsecure message between the source and the destination IP ports. STS Thisfield is valid only with Completion packets. Specifies the status of thecorresponding Non-posted transaction, (i.e. either a successfulcompletion or a failed transaction). RSVD This is a reserved field thatcan also be used to transport a private or secure message between thesource and the destination IP ports. FMT Specifies the formatspecification if multiple header formats are defined and used. BE ByteEnable, indicates which bytes in the payload are valid.

The payload 36 contains the contents of the packet. The size of thepayload may vary. In some instances, the payload may be large. In otherinstances, it could be small. In yet other instances, if the content isvery small or “compact”, it can be transported in the USRD field of theheader 34.

The type of transaction will often dictate whether or not the packet(s)used to represent the transaction has/have payloads or not. For examplewith either a Posted or Non-posted read, the packet(s) will designatethe location address to be accessed, but will typically have no payload.The packets for the related Completion transaction, however, willinclude payload(s) containing the read content. With both Posted andNon-posted write transactions, the packet(s) will include a payloadcontaining the data to be written to the destination. With Non-postedversions of a write, the packets for the Completion transaction willordinarily not defined a payload. However, in some situations, aCompletion transaction will define a payload.

The exemplary packet and above description covers many of basic fieldsthat may be included in a packet. It should be understood thatadditional fields may be deleted or added. For instance, a privatesignaling field may be used so a source and a destination may shareprivate messages.

Arbitration

Referring to FIG. 3A, a logic diagram illustrating the arbitration logicperformed by the arbitration element 26 with Peripheral ComponentInterconnect (PCI) ordering is shown.

With PCI ordering, each Port 20 includes separate buffers for eachvirtual channel and transaction class (P, NP and C) combination. Forinstance, with four virtual channels (VC0, VC1, VC2 and VC3), the Ports0, Port 1 and Port 2 each have twelve first-in, first-out buffers. Inother words for each Port 20, a buffer is provided for each transactionclass (P, NP, and C) and virtual channel (VC0, VC1, VC2 and VC30combination.

As each IP agent 14 (e.g., IP₁, IP₂ and IP₃) generates transactions, theresulting packets are placed in the appropriate buffer, based ontransaction type, in the corresponding port (e.g., Port 0, Port 1 andPort 2) respectively. For instance, Posted (P), Non-posted (NP) andCompletion (C) transactions generated by IP₁ are each placed in thePosted, Non-posted and Completion buffers for the assigned virtualchannel in Port 0 respectively. Transactions generated by IP₂ and IP₃are similarly placed in the Posted, Non-posted and Completion buffersfor the assigned virtual channels in Ports 1 and Port 2 in a similarmanner.

If a given transaction is represented by multiple packets, all of thepackets of that transaction are inserted into the same buffer. As aresult, all of the packets of the transaction are eventually transmittedover the same virtual channel With this policy, the virtual channelsremain independent, meaning different virtual channels are not used fortransmission of multiple packets associated with the same transaction.

Within each port 20, packets can be assigned to a given virtual channelin a number of different ways. For instance, the assignment can bearbitrary. Alternatively, the assignment can be based on workload andthe amount of outstanding traffic for each of the virtual channels. Ifone channel is very busy and the other not, then the port 20 will oftenattempt to balance the load and assign newly generated transactiontraffic to under-utilized virtual channels. As a result, routingefficiency is improved. In yet other alternatives, transaction trafficcan be assigned to a particular virtual channel based on urgency,security, or even a combination of both. If a certain virtual channel isgiven a higher priority and/or security than others, then high priorityand/or secure traffic is assigned to the higher priority virtual channelIn yet other embodiments, a port 20 can be hard-coded, meaning the port20 has only one virtual channel and all traffic generated by that port20 is transmitted over the one virtual channel In yet other embodiments,the assignment can be based on the route chosen to reach the destinationport 20.

In yet other embodiments, the assignment of virtual channels can beimplemented by the source IP agents 14, either alone or in cooperationwith its corresponding port 20. For example, a source IP agent 14 cangenerate a control signal to the corresponding port 20 requesting thatpacket(s) of a given transaction be assigned to a particular virtualchannel IP agents 14 can also make assignment decisions that arearbitrary, hard coded, based on balanced usage across all the virtualchannels, security, urgency, etc., as discussed above.

In selecting an arbitration winner, the arbitration element 26 performsmultiple arbitration steps per cycle. These arbitration steps include:

-   -   (1) Selecting a port;    -   (2) Selecting a virtual channel; and    -   (3) Selecting a transaction class.

The above order (1), (2) and (3) is not fixed. On the contrary, theabove three steps may be completed in any order. Regardless of whichorder is used, a single arbitration winner is selected each cycle. Thewinning transaction is then transmitted over the corresponding virtualchannel associated with the interconnect 12.

For each arbitration (1), (2) and (3) performed by arbitration element26, a number of arbitration schemes or rule sets may be used. Sucharbitration schemes may include strict or absolute priority, a weighedpriority where each of the four virtual channels is assigned a certainpercentage of transaction traffic or a round-robin scheme wheretransactions are assigned to virtual channels in a predefined sequenceorder. In additional embodiments, other priority scheme such may beused. Also, it should be understood that the arbitration element 26 maydynamically switch among the different arbitration schemes fromtime-to-time and/or use the same or different arbitration schemes foreach of the (1), (2) and (3) arbitrations respectively.

In an optional embodiment, availability of the destination ports 20defined by the outstanding transaction(s) considered during a givenarbitration cycle are considered. If a buffer in a destination port 20does not have the resources available to process a given transaction,then the corresponding virtual channel is not available. As a result,the transaction in question does not compete in the arbitration, butrather, waits until a subsequent arbitration cycle when the targetresource becomes available. On the other hand, when target resource(s)is/are available, the corresponding transaction(s) are arbitrated andcompete for access to the interconnect 12.

The availability of the destination ports 20 may be checked at differenttimes with respect to the multiple arbitration steps (1), (2) and (3)noted above. For instance, the availability check can be performed priorto the arbitration cycle (i.e., prior to completion of any of steps (1),(2) and (3)). As a result, only transactions that define availabledestination resources is/are considered during the subsequentarbitration. Alternatively, the availability check can be performedintermediate any of the three arbitration steps (1), (2) and (3),regardless of the order in which they are implemented.

There are advantages and disadvantages in performing the destinationresource availability check early or late in the arbitration process. Byperforming the check early, possible competing portions of transactionscan potentially be eliminated from the competition if their destinationsare not available. However, early notice of availability may create asignificant amount of overhead on system resources. As a result,depending on circumstances, it may be more practical to perform theavailability check later in a given arbitration cycle.

For the arbitration step involving the selection of a transaction class,a number of rules are defined to arbitrate among competing portions ofN, NP and C transactions. These rules include:

For Posted (P) Transactions

-   -   A Posted transaction portion may not pass another Posted        transaction portion;    -   A Posted transaction portion must be able to pass a Non-posted        transaction portion to avoid deadlock;    -   A Posted transaction portion must be able to pass a Completion        if both are in a strong order mode. In other words in the strong        mode, the transaction need to be performed strictly in        accordance with the rules and the rules cannot be relaxed; and    -   A Posted request is permitted to pass a Completion, but passage        is not mandatory, if any transaction portion has its Relaxed        Order (RO) bit set. With relaxed order, the rules are generally        followed, however exceptions can be made.

For Non-posted (NP) Transactions

-   -   A Non-posted transaction portion must not pass a Posted        transaction portion;    -   A Non-posted transaction portion must not pass another        Non-posted transaction portion;    -   A Non-posted transaction portion must not pass a Completion if        both are in the strong order mode; and    -   A Non-posted transaction portion is permitted to pass a        Completion, but is not mandatory, if any transaction portion has        its RO bit set.

For Completion (C) Transactions

-   -   A Completion must not pass a Posted transaction portion if both        are in the strong order mode;    -   A Completion is permitted to pass a Posted transaction portion,        but is not mandatory, if any transaction portion has its RO bit        set;    -   A Completion must not pass a Non-posted transaction portion if        both are in the strong order mode;    -   A Completion is permitted to pass a Non-posted transaction        portion, but is not mandatory, if any transaction portion has        its RO bit set; and    -   A Completion is not permitted to pass another Completion.

Table IV below provides a summary of the PCI ordering rules. In theboxes with no (a) and (b) options, then the strict ordering rules needto be followed. In the boxes of the Table having (a) and (b) options,either strict order (a) or relaxed order (b) rules may be applied,depending on if the RO bit is reset or set respectively. In variousalternative embodiments, the RO bit can be set or reset either globallyor on individually on the packet level.

TABLE IV Posted Non-posted Request Request Completion Row Pass Column?(Column 2) (Column 3) (Column 4) Posted Request No Yes (a) Yes Row A (b)Y/N Non-posted Request No No (a) No Row B (b) Y/N Completion (a) No (a)Yes No Row C (b) Y/N (b) Y/N

The arbitration element 26 selects an ultimate winning transactionportion by performing, in no particular order, arbitrations amongcompeting Ports 20, virtual channels and transactions classesrespectively. The winning portion per cycle gains access to the sharedinterconnect 12 and is transmitted over the corresponding virtualchannel.

Referring to FIG. 3B, a logic diagram illustrating the arbitration logicperformed by the arbitration element 26 with Device ordering is shown.The arbitration process, and possibly the consideration of availabledestination resources, is essentially the same as described above,except for two distinctions.

First, with Device ordering, there are only two transaction classesdefined, including (a) Non-posted read or write transactions where aresponse for every request is required and (b) Completion transactions,which defined the required responses. Since there are only twotransaction classes, there are only two (2) buffers per virtual channelin each Port 20. For instance, with four (4) virtual channels (VCO, VC1,VC2 and VC3), each Port 20 (e.g., Port 0, Port 1 and Port 2) has a totalof eight (8) buffers.

Second, the rules for selecting a Transaction for Device ordering arealso different than PCI ordering. With Device ordering, there are nostrict rules governing the selection of one class over the over class.On the contrary, either transaction class can be arbitrarily selected.However, common practice typically calls for favoring Completiontransactions to free up resources that may not be available until aCompletion transaction is resolved.

Otherwise, the arbitration process for Device order is essentially thesame as described above. In other words for each arbitration cycle, thearbitration steps (1), (2) and (3) are performed, in any particularorder, to select an arbitration winner. When the transaction classarbitration is performed, Device order rather than PCI order rules areused. In addition, the availability of destination resources and/orvirtual channels may also be considered either prior to or intermediateany of the arbitration steps (1), (2) and (3).

Operational Flow Diagram

As previously noted, the above-described arbitration scheme can be usedfor sharing access to any shared resource and is not limited to use withjust a shared interconnect. Such other shared resources may include theARL 28, a processing resource, a memory resource such as the LUT 30, orjust about any other type of resource that is shared among multipleparties vying for access.

Referring to FIG. 4, a flow diagram 40 illustrating operational stepsfor arbitrating access to a shared resource is shown.

In step 42, the various source sub-system agents 14 generatetransactions. The transactions can be any of the three classes,including Posted (P), Non-posted (NP) and Completion (C).

In step 44, each of the transactions generated by the source sub-systemagents 14 are packetized. As previously noted, packetization of a giventransaction may result in one or multiple packets. The packets may alsovary in size, with some packets having large payloads and others havingsmall or no payloads. In situations where a transaction is representedby a single packet having a data payload 36 that is smaller than thewidth of the interconnect 12, the transaction can be represented by asingle portion. In situations where a transaction is represented bymultiple packets, or a single packet with a data payload 36 that islarger than the access width of the shared resource, then multipleportions are needed to represent the transaction.

In step 46, the portion(s) of the packetized transactions generated byeach of the sub-system agents 14 are injected into the local switch 16via its corresponding port 20. Within the port 20, the packet(s) of eachtransaction are assigned to a virtual channel As previously noted, theassignment can be arbitrary, hard coded, based on balanced usage acrossall the virtual channels, security, urgency, etc.

In step 48, the portion(s) of the packetized transactions generated byeach of the sub-system agents 14 are stored in the appropriate,first-in, first-out, buffer by both transaction class and by theirassigned virtual channel (e.g., VC0, VC1, VC2 and VC3) respectively. Aspreviously noted, virtual channels may be assigned by one of a number ofdifferent priority schemes, including strict or absolute priority,round-robin, weighted priority, least recently serviced, etc. If a giventransaction has multiple portions, each portion will be stored in thesame buffer. As a result, the multiple portions of a given transactionare transmitted over the same virtual channel associated with theinterconnect 12. As transaction portions are injected, the correspondinga counter for tracking the number content items in each buffer isdecremented. If a particular buffer is filled, its counter isdecremented to zero, meaning the buffer can no longer receive additionalcontents.

In steps 50, 52 and 54, first, second and third level arbitrations areperformed. As previously noted, the selection of a Port 20, a virtualchannel and a transaction class can be performed in any order.

Element 56 may be used to maintain the rules used to perform the first,second and third levels of arbitration. In each case, the element 56 isused as needed in resolving each of the arbitration levels. Forinstance, element 56 may maintain PCI and/or Device ordering rules.Element 56 may also contain rules for implementing several priorityschemes, such as strict or absolute priority, weighted priority, roundrobin, etc., and the logic or intelligence for deciding which to use ina given arbitration cycle.

In step 58, a winner of the arbitration is determined. In step 60, thewinning portion is placed in a buffer used for accessing the sharedresource and a counter associated with the buffer is decremented.

In step 62, the buffer associated with the winning portion isincremented since the winning portion is no longer in the buffer.

In step 64, the winning portion gains access to the shared resource.Once the access is complete, the buffer for the shared resource isincremented

The steps 42 through 64 are continually repeated during successive clockcycles respectively. As different winning portions, each gains access tothe shared resource.

Interleaving—Example One

Transactions can be transmitted over the interconnect 12 in one ofseveral modes.

In one mode, referred to as the “header in-line” mode the header 34 ofpacket(s) 32 of a transaction are always transmitted first ahead of thepayload 36 in separate portions or beats respectively. The headerin-line mode may or may not be wasteful of the bits available on theinterconnect 12, depending the relative size of the header 34 and/or thepayload 36 with respect to the number of data bits N of the interconnect12. For instance, consider an interconnect 12 that is 512 bits wide(N=512) and a packet having a header that is 128 bits and a payload of256 bits. With this scenario, the 128 bits of the header are transmittedin a first portion or beat, while the remaining 384 bits of bandwidth ofthe interconnect 12 are not used. In a second portion or beat, the 256bits of the payload 36 are transmitted, while the remaining 256 bits ofthe interconnect 12 are not used. In this example, a significantpercentage of the bandwidth of the interconnect is not used during thetwo beats. On the other hand if the majority of the packets oftransactions are the same size or larger than the interconnect, than thedegree of wasted bandwidth is reduced or possibly eliminated. Forexample with headers and/or payloads that are 384 or 512 bits, theamount of waste is either significantly reduced (e.g., with 384 bits) oreliminated altogether (e.g., with 512 bits).

In another mode, referred to as “header on side-band”, the header 34 ofa packet is transmitted “on the side” of the data, meaning using thecontrol bits M, while the payload 36 is transmitted over the N data bitsof the interconnect 12. With the header on side band mode, the number ofbits or size of the payload 36 of a packet 32 determines the number ofbeats needed to transmit the packet over a given interconnect 12. Forinstance, with a packet 32 having a payload 36 of 64, 128, 256 or 512bits and an interconnect 12 having 128 data bits (N=128), the packetrequires 1, 1, 2 and 4 beats respectively. With the transmission of eachof the beat(s), the header information is transmitted over the controlbits M along with or “on the side” of the data of the payload over the Ndata bits of the interconnect 12.

In yet another mode, the header 34 of packets 32 are transmitted in linewith the payload, but there is no requirement that the header 34 and thepayload 36 must be transmitted in separate portions or beats. If apacket 32 has a header 34 that is 128 bits and a payload 36 that is 128bits, then the total size is 256 bits (128+128). If the N data bits ofinterconnect 12 is 64, 128, 256 or 512 bits wide, then a packet of 256bits is transmitted in 4, 2, 1 and 1 beats respectively. In anotherexample, a packet 32 has a header of 128 bits and a payload 36 of 256bits, or a total packet size of 384 bits (128+256). With the sameinterconnect 12 of N data bits of 64, 128, 256 or 512 wide, the packetis transmitted in 6, 3, 2, or 1 beats respectively. This mode willalways be as least as efficient or more efficient as the header in-linemode described above.

Referring to FIG. 5, a first example of the interleaving of portions ofdifferent transactions over multiple virtual channels is illustrated. Inthis example, for the sake of simplicity, only two transactions aredefined. The two transactions are competing for access to sharedinterconnect 12, which is 128 data bits wide (N=128) in this example.The details of the two transactions include:

-   -   (1) Transaction 1 (T1), which was generated at Time T1 and which        is assigned to virtual channel VC2. The size of T1 is four        beats, designated as T1A, T1B, T1C and T1D; and    -   (2) Transaction 2 (T2), which was generated at Time T2 (after        Time T1) is assigned to virtual channel VC0. The size of T2 is a        single portion or beat.

In this example, VCO is assigned absolute or strict priority. Over thecourse of multiple cycles, the portions of the two transactions T1 andT2 are transmitted over the shared interconnect, as depicted in FIG. 5,as follows:

-   -   Cycle 1: Beat T1A of T1 is transmitted over VC2 because it is        the only available transaction;    -   Cycle 2: Beat T1B of T1 and the single portion of T2 are        competing for access to the interconnect 12. Since VCO has        strict priority, T2 automatically wins. Accordingly, the beat of        T2 is transmitted over VC0.    -   Cycle 3: Since there are no competing transactions, beat T1B of        T1 is transmitted over VC2.    -   Cycle 4: Since there are no competing transactions, beat T1C of        T1 is transmitted over VC2.    -   Cycle 5: Since there are no competing transactions, beat T1D of        T1 is transmitted over VC2.

This example illustrates (1) with a virtual channel with absolutepriority, access to the shared interconnect 12 is immediately awardedwhenever traffic becomes available, regardless of whether or not othertraffic has been previously waiting and (2) the winning portions orbeats of different transactions are interleaved and transmitted overdifferent virtual channels associated with the interconnect 12. In thisexample, virtual channel VCO was given absolute priority. It should beunderstood that with absolute or strict priority schemes, any of thevirtual channels may be assigned the highest priority.

Interleaving—Example Two

Referring to FIG. 6, a second example of the interleaving of portions ofdifferent transactions over multiple virtual channels is illustrated.

In this example, the priority scheme for access to the interconnect 12is weighted, meaning VCO is awarded access (40%) of the time and VC1-VC3are each awarded access (20%) of the time respectively. Also, theinterconnect is 128 bits wide.

Further in this example, there are four competing transactions, T1, T2,T3 and T4:

-   -   T1 is assigned to VC0 and includes four (4) portions or beats        T1A, T1B, T1C and T1D;    -   T2 is assigned to VC1 and includes two (2) portions or beats T2A        and T2B;    -   T3 is assigned to VC2 and includes two (2) portions or beats T3A        and T3B;    -   T4 is assigned to VC3 and includes two (2) portions or beats T4A        and T4B.

With this example the priority scheme is weighed. As a result, eachvirtual channel will win according to its weight ratio. In other wordsover the course of ten cycles, VCO will win four times and VC1, VC2 andVC3 will each win two times. For instance, as illustrated in FIG. 6:

-   -   The four portions or beats T1A, T1B, T1C and T1D of T1 are        transmitted over VCO in four (40%) of the ten (10) cycles (i.e.,        cycles 1, 4 7 and 10);    -   The two portions or beats of T2A and T2B of T2 are transmitted        over VC1 in two (20%) of the ten (10) cycles (i.e., cycle 2 and        cycle 6);    -   The two portions or beats of T3A and T3B of T3 are transmitted        over VC2 in two (20%) of the ten (10) cycles (i.e., cycle 5 and        cycle 9); and    -   The two portions or beats of T4A and T4B of T4 are transmitted        over VC3 in two (20%) of the ten (10) cycles (i.e., cycle 3 and        cycle 8);

This example thus illustrates: (1) a weighted priority scheme where eachvirtual channel is awarded access to the interconnect 12 based on apredetermined ratio and (2) another illustration of the winning portionsof different transactions being interleaved and transmitted overdifferent the virtual channels associated with the interconnect 12.

It should be understood with this weighted example there is sufficienttraffic to allocate portions of transactions to the various virtualchannels in accordance with the weighted ratios. If the amount oftraffic on the other hand is insufficient, then the weighted ratios canbe either strictly or not strictly enforced. For example, if there is alarge degree of traffic on virtual channel VC3 and limited to no trafficon the other virtual channels VC0, VC1 and VC2, then VC3 will carry allor a bulk of the traffic if the weighted ratio is strictly enforced. Asa result, however, the interconnect 12 may be under-utilized as portionsof transactions may not be sent every clock cycle or beat. On the otherhand if the weighted ratio is not strictly enforced, then it is possiblefor the transaction traffic to be reallocated to increase theutilization of the interconnect (e.g., traffic is sent over a highernumber of cycles or beats).

The above two examples are applicable regardless which of theabove-described transmission modes are used. Once transaction(s) is/aredivided into portions or beats, they can be interleaved and transmittedover the shared interconnect 12 using any of the arbitration schemes asdefined herein.

The above-described arbitration schemes represent just a few examples.In other examples, low jitter, weighted, strict, round-robin or justabout any other arbitration scheme may be used. The arbitration schemeslisted or described herein should therefore be considered as exemplaryand not limiting in any manner.

Multiple Simultaneous Arbitrations

Up to now, for the sake of simplicity, only a single arbitration hasbeen described. It should be understood, however, that in real-worldapplications, such as on a SoC, multiple arbitrations may occursimultaneously.

Referring to FIG. 7, a block diagram of two shared interconnects 12 and12Z for handling traffic in two directions between switches 16, 18 isillustrated. As previously described, the switch 16 is responsible fordirecting transaction traffic from source sub-functions 14 (i.e., IP₁,IP₂ and IP₃) to destination sub-functions 14 (i.e., IP₄, IP₅ and IP₆)over the shared interconnect 12. To handle transactional traffic in theopposite direction, switch 18 includes arbitration element 26Z andoptionally ARL 28Z. During operation, elements 26Z and ARL 28Z operatein the complement of that described above, meaning transaction trafficgenerated by source IP agents 14 (i.e., IP₄, IP₃ and IP₆) is arbitratedand sent over shared interconnect 12Z to destination IP agents (i.e.,IP₁, IP₂ and IP₃). Alternatively, the arbitration can be performedwithout the ARL 28Z, meaning the arbitration simply decides amongcompeting ports 20 (e.g., Port 3, port 3 or Port 5) and the portion ofthe transaction associated with the winning port is transmitted over theinterconnect 12, regardless of the final destination of the portion. Aselements 12Z, 26Z and 28Z have previously been described, a detailedexplanation is not provided herein for the sake of brevity.

In a SoC, there can be multiple levels of sub-functions 14 and multipleshared interconnects 12. With each, the above described arbitrationscheme can be used to arbitrate among transactions sent over theinterconnects 12 between the various sub-functions simultaneously.

IP Agent Reset and Power Management

Referring to FIG. 8, a block diagram of an SoC 800 having reset andpower management functionality is illustrated. The SoC 800 includes aninterconnect 802, a plurality of IP agents 14 (e.g., Agent 1 throughAgent N), one or more links 803 connecting or coupling the IP agents 14to the interconnect 802, and a system controller 804. Although notillustrated, each IP agent 14 may also include one or more dedicated“hard-wire” inputs for receiving reset input instructions. Suchinstructions may come from a number of sources, including from off theSoC, the system controller 804, or another IP agent 14, etc.

In various embodiments, the IP agents 14 may be disparate and mayimplement a wide variety of different functions.

The interconnect 802 can be a wide variety of different types ofinterconnects, such a Network on a Chip (NoC), a bus, a switchingnetwork, etc.

In various embodiments, the links 803 may each be a dedicated link or abus between each IP agent 14 and the interconnect 802. Alternatively,access to the interconnect 802 can be shared among multiple IP agents 14using one link 803 and an arbitration scheme is used to select among thecompeting IP agents 14. In yet another embodiment, a number of virtualchannels may be associated with the one or more links 803, such as thevirtual channels associated with the shared link as previouslydescribed.

The system controller 804 and the managers 806, 808 and 809 may also beimplemented in a number of different ways. For instance, as a CPU ormicrocontroller, as programmable logic, a complex state machine forhandling all or most system control functions on the SoC 800, a simplestate machine for handling a few exception situations, or anycombination thereof. The system controller 804 may reside on the SoC 800as shown or, alternatively, located off the SoC 800 (not illustrated).Where a state machine is used, the states and the transitions betweenthe states is typically hard-coded into the SoC 800.

In yet other embodiments, one or more of the reset, power and/or quiescemanagers 806, 808 and 809 can each be centralized within the systemcontroller 804 as shown. Alternatively, each manager 806, 808 and/or 809can be decentralized and distributed throughout various locations on theSoC 800 or even off the SoC. Each of the reset manager 806, the powermanager 808 and the quiesce manager 809 can be implemented in software,hardware, programmable logic, a state machine or any other suitablemeans.

The reset manager 806 is responsible for managing the emergence of thevarious IP agents 14 on the SoC 800 from reset in an organized manner Areset of an IP agent 14 may be required or desired under a number ofcircumstances. For instance, a “cold reset” occurs following removal ordisruption of power provided to the SoC 800 or a system wide reset ofthe SoC 800. Alternatively, a “warm reset” occurs when one, a group oreven all the IP agents 14 (similar to a cold reset) are reset, but poweris not removed or disrupted from the SoC 800. A warm reset can beimplemented via signaling that originates either on the SoC 800 orexternally. Regardless of how a reset is initiated, the reset manager806 is responsible for managing the emergence of the IP agent 14 or IPagents 14 from reset in an organized manner.

If an IP agent 14 is malfunctioning for some reason, it may have to bereset. Examples of malfunctioning IP agents 14 include situations wherethe IP agent 14 is non-responsive, is in an error state, or activelygenerating erroneous transactions. In yet other examples, an IP agent 14may have to undergo a reset operation upon exiting a lower power state,such as one of several power saving modes as described below.

The power manager 808 manages the process of placing the various IPagents 14 into a lower power state, typically one of several powersaving modes. Depending on the mode, the power manager 808 may operatein cooperation with the reset manager 806 to reset an IP agent 14 ifnecessary.

The quiesce manager 809 operates in cooperation with the systemcontroller 804, reset manager 806, power manager 808 and theinterconnect 802 to (1) transition an operational or malfunctioning IPagent 14 into either a reset or a power savings mode where the IP agentbecomes inoperable, (2) places the link 803 between the interconnect andthe IP agent 802 into a quiescent state and (3) directs the interconnectto operate as a proxy for the IP agent while inoperable.

The memory 810 may include both volatile and non-volatile types ofmemory. In addition, the memory 810 may be centralized on the SoC 800 ormay be widely distributed among the system controller 804, theinterconnect 802, the links 803, and any of the managers 806, 808 and/or809. In yet other embodiments, portions or all of the memory 810 may beprovided off the SoC 800.

The volatile portions of the memory 810 are typically used for systemmemory, where the current data generated by the system controller 804,managers 806, 808, 809, interconnect 802, IP agents 14, etc., arestored. Such memory may include various caches, SRAM, DRAM, etc.

The non-volatile or persistent portions of memory 810 is typically usedfor storing “boot-up” code for the SoC 800. The boot code enables thesystem controller 804, including the managers 806, 808, 809, theinterconnect 802 and the IP agents 14, to each load their operatingsystems and/or other system software as needed to initiate operationafter powering on. The reboot process typically includes a number ofself-tests, which when completed, allow the entire system, includingeach of the IP agents 14, to perform their normal operations. Thenon-volatile or persistent portions may be implemented using NVRAM(non-volatile random-access memory), EEPROM (electrically erasableprogrammable read only memory), a hard drive, CD ROM, etc.

The reset manager 806 is responsible for coordinating the emergence fromreset of any of the IP agents 14 in an organized manner. As notedherein, a reset of a given IP agent 14 may occur for any number ofreasons, including (1) when the entire SoC 800 emerges from resetfollowing an external reset, a re-start command or a power-on event or(2) or an individual IP agent 14 reset during operation of the SoC 800due to malfunction, following a power down or sleep mode, etc.Regardless of the reason, a given IP agent 14 is ready to be introducedto the interconnect 802 once its internal reset sequence is complete.Upon emergence from reset, a negotiation is then coordinated between theIP agent 14 and its IP port 20 on the interconnect 802 over the link803.

Referring to FIG. 9 is a flow diagram showing an exemplary IP agentreset negotiation sequence between an IP agent 14 and the interconnect802.

In the initial step 902, a determination is made if an IP agent 14 hasemerged from reset and is ready to be introduced to the interconnect 802or not. When emergence occurs, the subsequent steps 904 through 912 arefollowed to reintroduce the IP agent 14 to the interconnect 802.

In step 904, the interconnect 802 generates inquires for the IP agent 14at periodic intervals. With each inquiry, the interconnect 802essentially asks the IP agent 14 if it is “awake” (i.e., is ittransaction ready, meaning is it capable of sending or processingreceived transactions).

In decision 906, the interconnect determines if it has received apositive response to the inquiry(s) from the IP agent 14. If not, thenthe interconnect 802 continues to send the inquiries. If yes, then itsignifies to the interconnect 802 that the IP agent 14 has partiallycompleted its reset routine and is ready for the next phase of thenegotiation.

In step 908, the interconnect 802 and the IP agent 14 continue theirnegotiation by exchanging their credit information respectively. Theinterconnect 802 and the IP agent 14 each exchange with the other theavailable number of beats (i.e., the amount of data that can betransmitted over the link 803 per clock cycle. Each partner on opposingsides of the link 803, after the exchange, knows the available number ofcredits the other has as a result of this negotiation.

In an optional step 910, interconnect 802 and the IP agent 14 continuetheir negotiation by exchanging other useful information such assecurity credentials, an agreed upon number of virtual channels that maybe associated with the link 803 coupling the interconnect 802 and the IPagent 14, etc.

In the last step 912, when the negotiation is complete, the IP agent 14is declared “transaction ready”. In other words, the IP agent is readyto either process incoming transactions received from the interconnect802 or to send outgoing transactions over the interconnect 802 toanother destination. Once the IP agent 14 is transaction ready, itbecomes visible to both the interconnect 802, the system controller 804and any other element connected or otherwise coupled to the interconnect802, either directly or indirectly through intermediate circuitry, logicor other element.

The reset manager 806 is also responsible for coordinating the reset ofmalfunctioning IP agents 14. During operation of the SoC 800, an IPagent 14 may misbehave (e.g., become non-responsive, enter an errorstate, erroneously generate transactions, or otherwise malfunction). Forinstance, the IP agent may be unable to process a received transaction.As a result, the originating IP agent that sent the transaction may gethung up waiting for a response. Depending on the severity of theproblem, the hang up can be limited to just the originating IP agent 14,the destination IP agent 14, or in a worst case scenario, other portionsor even the entire SoC 800 may be adversely affected. Accordingly, incertain circumstances, the misbehaving IP agent may need to be reset tocorrect the issue.

Referring to FIG. 10, a flow diagram 1000 showing a reset sequence for amalfunctioning IP agent is shown.

In step 1002, the various IP agents 14 on the SoC 800 operate as normalby generating transmitted transactions and/or processing receivedtransactions.

In decision step 1004, the system controller 804 monitors the operationof the IP agents. If no problems are detected, then the IP agents 14continue their normal operation. On the other hand if an IP agentmalfunctions, for any reason, then the reset manager 806 flags it as amalfunctioning IP agent 14.

In step 1005, the system controller 804 and interconnect 802 furthercooperate to initiate a number of processes that help the remainder ofthe SoC 800 operate without further issues or problems. These additionalprocesses may include:

-   -   1. The system controller 804 requests that the interconnect 802        disallow any further transactions from being generated by the        malfunctioning IP agent 14;    -   2. 2. Keeping track of outstanding transactions targeting the        malfunctioning IP agent 14;    -   3. 3. The interconnect 802 may act as a proxy and respond to any        transactions targeted for the malfunctioning IP agent 14 while        undergoing the reset negotiation process. For example, the        interconnect 802 may generate an exception message in response        to the non-processed transaction. By acting as a proxy,        potentially much larger system wide issues are avoided,        including the entire system getting hung up because the sender        of the transaction never received a response from the        malfunctioning IP agent 14. In various embodiments, the        exception message may be a number of different types, such as        the IP agent 14 is not available, the IP agent is in a low power        mode, etc. In general, a wide variety of different types of        exception messages may be used, each indicative of the condition        or error that has occurred.

In step 1006, the reset manager 806 generates a reset instruction forthe malfunctioning IP agent 14.

In 1007, the link 803 between the IP agent 14 to be reset and theinterconnect 802 is placed in a quiescent state. This process is furtherdescribed with regard to FIG. 14.

In step 1008, the malfunctioning IP agent 14 initiates its reset routinein response to the instruction received over the interconnect 802 orwhich may be received via a dedicated reset wire. This process involvesthe IP agent 14 (1) executing its own reset protocol or routine and (2)negotiating with the interconnect 802, as described above with regard toFIG. 9.

In decision step 1012, it is determined if the reset negotiation of theIP agent 14 is complete. When complete, control returns to step 1002 andoperation of the IP agents 14 and the SoC 800 resume as normal. As notedabove, the reset IP agent 14 becomes visible to the interconnect 802 andthe system controller after emerging from the reset and becomestransaction ready. Finally, in step 1014, the link 803 between the nowreset IP agent 14 and the interconnect 802 exits the quiescent mode. Atthis point, the interconnect 802 no longer needs to act as a proxy forthe IP agent 14.

The power manager 808 is responsible for intelligently and selectivelyplacing IP agents 14 into a lower power state, by placing the IP agents14 in one of several power down modes. The powering down or placing ofIP agents 14 into a powered down mode can be performed for a variety ofreason.

For example, if the SoC 800 is used in a battery powered device, thepower manager 808 may place IP agents into a power down mode to preservelimited battery power. Alternatively, even in non-battery powereddevices, the power manager 808 may place non-critical IP agents 14 intoa low power mode to prevent overheating. These are just a few of thepossible reasons for implementing power management. Other reasons mayinclude placing one or more IP agents 14 in a power down mode if theyare not being used. In various alternative embodiments, the power downmodes include:

-   -   1. Low Power Mode, Operational: In one alternative, the clock        frequency for the IP agent 14 is slowed down if applicable.        Alternatively, the supply voltage may be reduced if applicable.        In yet another embodiment, both the clock frequency and supply        voltage may be reduced if applicable further reducing power        consumption. It should be understood that reducing the clock        frequency and/or supply voltage is done only when applicable,        meaning not all IP agents 14 have the ability to operate at        either a reduced clock frequency, a reduced supply voltage, or        both. In yet other embodiments, the commands for reducing the        clock and/or supply voltage, when applicable, can be derived        from the system controller 804 or the IP agent 14 itself,        provided the IP agent 14 has a low power, operational mode.    -    Since the IP agent remains functional, the interconnect 802 may        not play a significant role in this mode, meaning it may not        have to act as a proxy for the IP agent 14 and generate        responses for incoming transactions since the IP agent 14 can        generate the response itself However, the system controller 804        and/or interconnect 802 may reconfigure the link 803 settings        for the IP agent 14 since its performance capability may be        reduced while operating at the lower clock frequency. The        setting(s) that may possibly be changed include the arbitration        settings for the IP agent 14 or the possible a reduction in the        count of permitted outstanding transactions. When the IP agent        exits this Low Power Mode, the voltage is first increased (if        decreased) followed by an increase in the clock frequency (if        decreased) and any changes to the link 803 settings reverted        back to normal operational mode (if reconfigured).    -   2. Low Power, Inoperable Mode, State Information Maintained: In        this mode, the clock is shut off and the power supply is        reduced, but may not turned off completely. As a result, state        information maintained in memory in the IP agent 14 is retained.        Prior to entering this mode, the interconnect 802 “drains” the        transactions that the IP agent has already issued by preventing        new transactions from being initiated and waiting for        outstanding transactions to complete. Once all the transactions        are drained, the interconnect 802 may act as a proxy and perform        similar processes (1), (2) and (3) as described above with        regard to the resetting of a malfunctioning IP agent 14. When        the IP agent is returned to normal and exits this mode, the        voltage is first increased followed by an increase in the clock        frequency.    -   3. Low Power, Inoperable, Mode-No State Information Retained:        This mode is similar to mode 2 described immediately above,        except the power is reduced to a point where state information        maintained in the IP agent is lost. The interconnect 802        operates as a proxy as discussed above in this mode as well.        When powered back up, the IP agent is required to go through a        reset negotiation process, similar to that as described above        with regard to FIG. 9.    -   4. Power Off Mode: In this mode, the clock is turned off and        power is completely removed. The interconnect 802 operates as a        proxy as discussed above. Upon power up, the supply voltage is        first ramped up followed by the reset negotiation process as        described above with regard to FIG. 9.

FIG. 11 is a flow diagram 1100 illustrating a sequence for placing an IPagent 14 in and out of the Low Power, Operational Mode.

In the initial step 1102, the IP agent 14 on the SoC 800 operates in itsnormal mode, meaning the standard clock frequency and voltage are used.

In decision step 1104, conditions within the SoC 800 are monitored bythe system controller 804. If operating conditions are relatively normalor no event occurs triggering a power down of the IP agent 14, then theSoC and IP agent 14 continues to operate in its normal mode per step1102. However, if a trigger condition is met (e.g., a reduced batterysupply, overheating, etc.), then the power manager 808 may elect toplace the IP agent 14 into the low, power operational mode.

In an optional step 1106, the interconnect 802 may elect to reconfigurethe link 803. The reconfiguration may include changing the arbitrationsettings for the IP agent 14 or reducing the count of possibleoutstanding transactions to take into account the lower processingcapability of the IP agent when operating at the lower power mode.

In step 1108, the operating clock frequency of the IP agent 14 isreduced if applicable. With the reduced clock frequency, the IP agentconsumes less power.

In step 1110, the voltage supplied to the IP agent is reduced ifapplicable. By reducing the voltage, further power savings can berealized.

With the clock frequency and/or the voltage reduced, the IP agent 14remains operational. As a result, it is capable of processingtransactions, although possibly at a slower rate when operating at itsstandard clock frequency and/or supply voltage. In optional embodiments,the interconnect 802 can act as a proxy as described above or can beadjusted or reconfigured to take into account and support the lower rateof performance of the IP agent 14 in the low power mode. Since thesealternatives are optional, they do not necessarily have to beimplemented.

In decision step 1112, the IP agent 14 operates in the low power modeuntil a decision is made to resume normal operation. In which case, theIP agent 14 undergoes a sequence to resume normal operation.

In optional step 1114, the voltage is increase to the standard operatingvoltage if applicable (i.e., if the voltage was previously decreased).

In step 1116, the clock frequency is increased if applicable (i.e.,provided the clock was previously decreased. In step 1117, the IP agentreturns to normal operation.

Finally, in optional step 1118, the interconnect returns anyreconfigured interconnect setting to normal. At this point, the IP agentis ready to resume normal operation, as provided in step 1102.

Referring to FIG. 12, a flow diagram 1200 illustrating a sequence forpowering down/up an IP agent 14 in the Low Power, Inoperable, StateInformation maintained mode is illustrated.

In step 1202, the IP agent 14 operates in its normal mode.

In step 1204, a decision is made to operate the IP agent 14 in lowpower, inoperable, state information maintained mode.

In step 1206, the link 803 is placed in the quiescent state and theinterconnect 802 is configured to operate as a proxy for the IP agent14. This typically involves (1) disallowing any new transactions frombeing generated by the IP agent 14, (2) waiting for any outstandingtransactions to complete and then (3) acting as a proxy by responding toany transactions targeted for the IP agent 14. For example, theinterconnect 802 may send an exception message to the source of thenon-processed transaction, possibly preventing a hang up situation fromoccurring because the sender of the transaction never received aresponse from the IP agent 14.

In step 1208, the clock frequency of the IP agent 14 is reduced ifapplicable.

In step 1210, the operating voltage of the IP agent 14 is reduced ifapplicable. However, the voltage remains adequate so that memory orstorage elements in the IP agent 14 maintain their state information.

In decision 1212, the IP agent 14 remains in the lower power state untila decision has been made to resume normal operation. The systemcontroller 804, an event external to the SoC (e.g., a signal receivedfrom a sensor, signal received an external source, etc.), a timer, theIP agent itself or another IP agent, can all trigger the wake-up. Whenthis decision is made, the IP agent undergoes a sequence to resumenormal operation.

In steps 1214 and 1216, the voltage and clock frequency provided to theIP agent 14 are each increased if applicable. Since the stateinformation has been retained, the IP agent 14 resumes normal operationin step 1217.

In step 1218, link 803 exists the quiescent mode and the IP agentbecomes transaction ready and the interconnect 802 is notified that itlonger has to act as a proxy.

Referring to FIG. 13, a flow diagram 1300 illustrating a sequence forthe Low Power, Inoperable, Mode is illustrated. In this sequence, steps1202, 1206 and 1212 are the same as described above with regard to FIG.12. As such, a discussion of these steps are not repeated herein.

In steps 1302, a decision is made to power down the IP agent 14.Thereafter, the interconnect is configured as a proxy (step 1206) andthe clock for the IP agent 14 is turned off completely (if applicable)and/or the voltage is significantly reduced (if applicable) to the pointwhere state information is lost in step 1304. Without state information,when a decision is made to resume normal operation per step 1212, thevoltage is ramped up (if applicable) and clock turned on (if applicable)in step 1306. Thereafter, the IP agent 14 undergoes a reset operation,as previously described with regard to FIG. 9. Once the reset iscomplete, the IP agent 14 becomes transaction ready. The system thenwaits for the link to exit the quiescent mode in step 1310. Once theexit occurs, the IP agent is visible on the interconnect 802.Thereafter, in step 1312, the interconnect 802 no longer acts as a proxyfor the IP agent 14.

Finally, for the Power Off Mode, the sequence is the same as FIG. 13,except the power is turned off completely, as opposed to simply reduced.Otherwise the Power Off Mode sequence is the same. In this mode, the IPagent 14 consumes virtually no power, is inoperable, and theinterconnect 802 may act as a proxy on behalf of the IP agent.

Referring to FIG. 14, a flow chart 1400 illustrating the steps forplacing a link 803 in the quiescent state is illustrated.

In the initial step 1402, the system controller 804 makes a decisionthat an IP agent 14 should be either reset or placed in one of theinoperable power saving modes.

In step 1404, the IP agent 14 is instructed to stop generatingtransactions.

In decision 1406, the system determines if all outstanding transactionsare complete. For all outstanding Non-posted transactions, a Completiontransaction must be received (i.e., with read transactions, the accesseddata must be returned, with non-posted write transactions, anacknowledgement must be received). With Posted transactions, no responsetransaction is required. Posted transactions are therefore considered“complete” once they are sent by the IP agent.

In step 1408, the link 803 is placed in the quiescent state when all theoutstanding transactions are complete. Thereafter, the interconnect 802is configured as a proxy for the IP agent 14.

In step 1410, the IP agent is ready to placed in either reset or thedesired inoperable low power mode.

FIGS. 15A-15D show flow diagrams of various for IP agent “wake-up”sequences.

Referring to FIG. 15A a flow diagram 1500 illustrating anagent-initiated “wake-up” sequence is illustrated. In this embodiment,the wake up sequence is initiated by the IP agent, but implementedthrough the system controller 804.

In step 1502, an IP agent 14 in an inoperable state detects a wake-uptrigger event. Although an IP agent may be powered down or “off”, it mayremain at least partially functional in the sense that it maintains theability to detect when a wake-up trigger occurs. The wake-up trigger mayinclude a number of different types of events. For example, it could bean internal timer that causes the IP agent 14 to wake-up after apredetermined period of time, or it can be an event external to the SoC800, such as another device that wishes to communicate with the IP agent14. In step 1504, the IP agent sends a “wake-up” communication over itslink 803 to the interconnect 802. Again, although the link is in thequiescent state when its corresponding IP agent 14 is in an inoperablestate, it is capable of transmitting the wake-up signal to theinterconnect 802.

In step 1506, the interconnect 802 is configured to “listen” for awake-up signal from an inoperable IP agent. If the signal is detected,the interconnect 802 notifies the system controller 804.

In step 1508, the system controller 804 may send command(s) over theinterconnect 802 for the IP agent 14 to initiate its wake-up sequence.

In step 1510, the IP agent initiates its wake-up sequence in response tothe command(s).

With the embodiment described above, the IP agent 14 asks the systemcontroller to initiate the wake-up sequence. In response to a wake-upcommand from the system controller, the IP agent initiates its ownwake-up sequence. The system controller is therefore aware of the statusof the IP agent as it emerges from its inoperable state and becomesvisible on the interconnect 802.

FIG. 15B shows the sequence when the system controller 804 initiates awake-up of an IP agent 14. With this sequence, the system controller 804sends wake up command(s) to the IP agent in step 1508, and in response,the IP agent initiates its own wake up sequence in step 1510. In avariation of this embodiment (not illustrated), the wake up may beinitiated off the SoC 800 via the system controller 804. When the systemcontroller 804 receives the command(s), the above described process isinitiated.

FIG. 15C shows the sequence when the wake up command for an IP agent 14that originates off the SoC 800 and is implemented through the systemcontroller 804. With this sequence, the system controller 804 receivesthe command in step 1512. In response, the system controller sends awake up command to the IP agent in step 1508, and in response, the IPagent initiates its own wake up sequence in step 1510. With direct wakeup from off the SoC 800, the command is provided directly to the IPagent 14 via its hard-wire input. In response, the IP agent initiatesits own wake up sequence.

Referring to FIG. 15D, a flow diagram 1520 illustrating an IP agentinitiated and implemented wake up sequence is illustrated. In thisembodiment, a wake up condition, such as any of those noted above,occurs in step 1522. In response, the IP agent initiates its own wake upsequence in step 1524. In step 1526, the wake up sequence completes.Thereafter, in step 1528, the IP agent notifies the interconnect 802 andthe system controller 804, either directly or through the interconnect802, of its awoken status.

In the above examples, sequences for transitioning a single IP agentinto one of the above-described low power modes was described for thesake of simplicity. In actual embodiments, multiple IP agents 14 on anSoC may be powered down concurrently. If two or more are powered down ator around the same time, each would independently undergo one the abovedescribed sequences, depending on the mode.

Although only a few embodiments have been described in detail, it shouldbe appreciated that the present application may be implemented in manyother forms without departing from the spirit or scope of the disclosureprovided herein. Therefore, the present embodiments should be consideredillustrative and not restrictive and is not to be limited to the detailsgiven herein, but may be modified within the scope and equivalents ofthe appended claims.

What is claimed is:
 1. A System on a Chip (SoC), comprising: a pluralityof IP agents; an interconnect arranged to handle transactional trafficbetween the plurality of IP agents, the interconnect including a firstport and a second port; a first IP agent of the plurality of IP agents,the first IP agent configured to communicate with the interconnect usinga first link, the first link directly connecting the first IP agent tothe first port; a second IP agent of the plurality of IP agents, thesecond IP agent configured to communicate with the interconnect using asecond link, the second link directly connecting the second IP agent tothe second port; a reset manager configured to: enable the first IPagent and the second IP agent to become transaction-ready independent ofone another, the enabling involving individual reset negotiationsincluding a first reset negotiation over the first link and between thefirst port and the first IP agent, the first reset negotiationcomprising: determining that the first IP agent is capable of sendingtransactions or processing received transactions; responsive todetermining that the first IP agent is capable of sending transactionsor processing received transactions, exchanging information over thefirst link, the information including an amount of data capable of beingtransmitted over the first link; and responsive to exchanging theinformation including the amount of data capable of being transmittedover the first link, enabling the first IP agent to receive incomingtransactions from the interconnect or send outgoing transactions overthe interconnect.
 2. The SoC of claim 1, wherein: the link directlyconnects the first IP agent to the first port without intermediatecircuitry; and the reset negotiation does not require intermediatecircuitry between the first IP agent and the first port.
 3. The SoC ofclaim 1, wherein: the reset manager individually initiates a reset ofthe first IP agent in response to a reset trigger event, the first resetnegotiation being responsive to the reset of the first IP agent, thereset trigger event including at least one of the following: anemergence of the SoC from reset; or a command to reset the first IPagent.
 4. The SoC of claim 1, wherein: the individual reset negotiationsinclude a second reset negotiation over the second link and between thesecond port and the second IP agent.
 5. The SoC of claim 4, wherein: thefirst reset negotiation enables the first IP agent to becometransaction-ready on a first clock cycle; and the second resetnegotiation enables the second IP agent to become transaction ready on asecond clock cycle different from the first clock cycle.
 6. The SoC ofclaim 4, wherein: the first reset negotiation and the second resetnegotiation include a same set of negotiations, the same set ofnegotiations occurring between the first port and the first IP agent andthe second port and the second IP agent, respectively.
 7. The SoC ofclaim 4, wherein: the first reset negotiation and the second resetnegotiation are responsive to a first reset of the first IP agent and asecond reset of the second IP agent, respectively, the first reset andthe second reset being individual reset routines distinct from oneanother.
 8. The SoC of claim 1, wherein the first individual resetnegotiation is conducted using link-level information that is directlytransmitted over the first link between the first port and the first IPagent, the direct transmission not sent to another destination andunmodified by the first link, the other destination distinct from thefirst IP agent and the first port.
 9. The SoC of claim 1, wherein thefirst reset negotiation further comprises the interconnect transmittinga plurality of inquiries to determine that the first IP agent is capableof sending transactions or processing received transactions, theplurality of inquiries sent by the interconnect using the first link atperiodic intervals respectively.
 10. The SoC of claim 9, wherein: thefirst reset negotiation further comprises the first IP agenttransmitting signaling to the interconnect in response to receiving oneor more of the plurality of inquiries from the interconnect; anddetermining that the first IP agent is capable of sending transactionsor processing received transactions is responsive to the first IP agenttransmitting the signaling to the interconnect.
 11. The SoC of claim 1,wherein the first reset negotiation further comprises the first port andthe first IP agent exchanging security information.
 12. The SoC of claim1, wherein the first reset negotiation further comprises the first portexchanging an agreed upon number of virtual channels to be associatedwith the first link, the first link associated with one or more virtualchannels, the one or more virtual channels comprising: independentstreams of information for respective virtual channels; and assignedpriorities for the respective virtual channels, the assigned prioritiesat least including a higher priority enabling a virtual channel of theone or more virtual channels to have greater arbitrated access to theinterconnect when compared to another virtual channel of a lowerpriority.
 13. The SoC of claim 1, wherein: the first IP agent and thesecond IP agent comprise different circuitry; and the first link and thesecond link comprise a same circuitry.
 14. A method comprising: enablinga first IP agent and a second IP agent of a plurality of IP agents tobecome transaction-ready independent of one another, the first IP agentand the second IP agent communicatively coupled to an interconnect at afirst port and a second port, respectively, through a first link and asecond link, respectively, the enabling involving individual resetnegotiations including a first reset negotiation over the first link andbetween the first port and the first IP agent, the first resetnegotiation comprising: determining that the first IP agent is capableof sending transactions or processing received transactions; responsiveto determining that the first IP agent is capable of sendingtransactions or processing received transactions, exchanging informationover the first link, the information including an amount of data capableof being transmitted over the first link; and responsive to exchangingthe information including the amount of data capable of beingtransmitted over the first link, enabling the first IP agent to receiveincoming transactions from the interconnect or send outgoingtransactions over the interconnect.
 15. The method of claim 14, whereinthe individual reset negotiations include a second reset negotiationover the second link and between the second port and the second IPagent.
 16. The method of claim 15, wherein: the first reset negotiationenables the first IP agent to become transaction-ready on a first clockcycle; and the second reset negotiation enables the second IP agent tobecome transaction ready on a second clock cycle different from thefirst clock cycle.
 17. The method of claim 15, wherein: the first resetnegotiation and the second reset negotiation include a same set ofnegotiations, the same set of negotiations occurring between the firstport and the first IP agent and the second port and the second agent,respectively.
 18. The method of claim 15, wherein: the first resetnegotiation and the second reset negotiation are responsive to a firstreset of the first IP agent and a second reset of the second IP agent,respectively, the first reset and the second reset being individualreset routines distinct from one another.
 19. The method of claim 14,wherein the first reset negotiation further comprises the first port andthe first IP agent exchanging security information.
 20. The method ofclaim 14, wherein the first reset negotiation further comprises thefirst port exchanging an agreed upon number of virtual channels to beassociated with the first link, the first link associated with one ormore virtual channels, the one or more virtual channels comprising:independent streams of information for respective virtual channels; andassigned priorities for the respective virtual channels, the assignedpriorities at least including a higher priority enabling a virtualchannel of the one or more virtual channels to have greater arbitratedaccess to the interconnect when compared to another virtual channel of alower priority.